As critical data are increasingly stored in electronic form, it is imperative that the critical data be stored reliably in a tamper-proof manner. Furthermore, a growing subset of electronic data (e.g., electronic mail, instant messages, drug development logs, medical records, etc.) is subject to regulations governing long-term retention and availability of the data. Recent high-profiled accountability issues at large public companies have further caused regulatory bodies such as the Securities and Exchange Commission (SEC) to tighten their regulations. For instance, Securities Exchange Commission Rule 17a-4, which went into effect in May 2003, specifies storage requirements for email, attachments, memos, and instant messaging as well as routine phone conversations. A requirement in many such regulations is that data must be stored reliably in non-erasable, non-rewritable storage such that the data, once written, cannot be altered or overwritten. Such storage is commonly referred to as WORM (Write-Once Read-Many) storage as opposed to WMRM (Write-Many Read-Many) storage, which can be written many times.
Critical data requires some form of organization such that all of the data relevant to an enquiry can be promptly discovered and retrieved, typically within days and sometimes even within hours. Scanning all of the data in a large volume of data to discover entries that are relevant to an enquiry is not practical. Instead, the data requires organization with some form of direct access mechanism such as an index. Such access mechanisms require storage in WORM storage to prevent the access mechanisms from being tampered. Otherwise, an adversary may modify the direct access mechanism to logically modify the data; e.g., hide an object by removing an index entry or replace an object by modifying the index entry for the original object.
Furthermore, there is often a need to log small amounts of data to WORM storage, for instance, to maintain database logs or non-alterable audit trails of activity in a system. To manage index mechanisms and logs such that they cannot be tampered, some form of WORM storage is required that allows adding new index/log entries while preventing any of the committed entries from being modified.
Although conventional WORM storage technology has proven to be useful, it would be desirable to present additional improvements. Conventional WORM storage systems do not efficiently support index mechanisms and logs. Conventional WORM storage ensures that an object (e.g. file, object, block) is immutable after the object has been committed into the WORM storage system. To store index structures and logs in WORM storage, creation of new objects is required whenever new entries are committed, incurring both performance and space overhead and degrading locality of reference. To improve performance and space overhead, entries can be committed less frequently. However, entries that have not been committed are not guaranteed to be immutable or even to be persistent. Alternatively, a large collection of data can be indexed in a batch. However, this batch index is not available until an entire collection of data is received and indexed. Moreover, as data is added over a period of time, the system creates many indices, each of which may need to be searched to find a particular piece of data.
What is therefore needed is a system, a computer program product, and an associated method for providing an object to support index structures, logs, and audit trails in WORM storage. The need for such a solution has heretofore remained unsatisfied.